BLUEPRINT

1 Positionnement Et PéRimèTre Du Protocole

Chapitre 1 : Positionnement et périmètre du protocole

1.1 Rôle du CAP dans l'écosystème iFay

Le Control Authority Protocol (CAP) assume une responsabilité principale unique et clairement définie au sein de l'écosystème iFay : vérifier si un Fay (iFay ou coFay) a été autorisé par son hôte humain (Natural_Person) ou son poste officiel (Official_Post) à accéder légitimement aux ressources du terminal (Terminal_Resource).

Concrètement, le protocole CAP est responsable des tâches suivantes :

Vérification d'autorisation : Lorsqu'un Fay demande l'accès à des ressources logicielles ou matérielles sur un terminal, le protocole CAP vérifie si les justificatifs d'autorisation qu'il présente (Authorization_Descriptor ou Trusted_Ticket) sont légitimes, valides et n'ont pas été révoqués. Par exemple, lorsque l'iFay d'un utilisateur souhaite ouvrir l'appareil photo du téléphone pour prendre une photo, le terminal doit d'abord vérifier que cet iFay a bien été autorisé par l'utilisateur à utiliser l'appareil photo
Gestion des sessions : Établissement de sessions de contrôle (Sessions) pour les Fays ayant passé la vérification d'autorisation, et gestion du cycle de vie complet de ces sessions. Par exemple, après qu'un iFay a été autorisé et commence à utiliser le navigateur, l'ensemble du processus depuis l'ouverture jusqu'à la fermeture du navigateur constitue une session de contrôle complète
Coordination du contrôle : Coordination de l'attribution et du transfert du contrôle des ressources du terminal entre plusieurs Fays ou entre Fays et utilisateurs humains. Par exemple, un drone piloté manuellement doit être transféré à un Fay pour un vol autonome ; ou deux iFays doivent utiliser la même imprimante successivement
Hiérarchisation de l'accès aux ressources : Gestion hiérarchisée de l'accès aux ressources par type d'opération (lecture, écriture, exécution, configuration). Par exemple, un iFay qui lit les données d'un capteur de température n'a besoin que de la permission read, tandis que la modification du réglage de température du climatiseur nécessite la permission write
Détection de vivacité : Surveillance de l'état de vivacité des sessions actives et récupération rapide des ressources occupées par les sessions expirées. Par exemple, après qu'un iFay a perdu la connexion suite à une interruption réseau, le terminal détecte un dépassement de délai du heartbeat et libère automatiquement le contrôle de l'appareil photo détenu par cet iFay, empêchant les ressources d'être verrouillées indéfiniment par des « sessions zombies »

Le protocole CAP est le pont essentiel reliant les agents intelligents aux ressources du terminal dans l'écosystème iFay — il ne se préoccupe pas de l'identité d'un Fay ni de ses capacités, mais uniquement de savoir si un Fay est autorisé à effectuer une action donnée.

1.2 Responsabilités hors du périmètre du CAP

Afin de garantir des limites de responsabilité claires, le protocole CAP ne prend explicitement pas en charge les éléments suivants :

Création et gestion de l'identité des Fays : L'enregistrement des entités Fay, l'attribution des identifiants, la maintenance des attributs d'identité et autres tâches sont gérés par le sous-système de gestion des identités de l'écosystème iFay. Le CAP consomme uniquement les informations d'identité pour la vérification d'autorisation et ne participe pas au processus de création et de gestion des identités. Par exemple, « comment s'appelle cet iFay et à qui appartient-il » est déterminé par le système de gestion des identités ; le CAP se préoccupe uniquement de « cet iFay est-il autorisé à utiliser l'appareil photo »
Capacités de raisonnement intelligent des Fays : La manière dont un Fay comprend l'intention de l'utilisateur, planifie les étapes opérationnelles et effectue un raisonnement intelligent relève de la couche d'intelligence propre au Fay et n'a aucun rapport avec le protocole CAP. Le CAP ne fait aucune hypothèse ni exigence concernant le niveau d'intelligence d'un Fay. Par exemple, un iFay décide d'abord d'ouvrir le navigateur puis de rechercher des billets d'avion — ce processus de décision n'a rien à voir avec le CAP ; le CAP n'effectue la vérification d'autorisation que lorsque l'iFay demande effectivement l'ouverture du navigateur
Logique métier spécifique des ressources du terminal : La manière dont les logiciels du terminal répondent aux commandes opérationnelles et dont le matériel exécute des fonctions spécifiques relève de la responsabilité des ressources du terminal elles-mêmes. Le CAP est uniquement responsable de la vérification d'autorisation et du contrôle d'accès, et n'intervient pas dans le traitement métier spécifique des ressources. Par exemple, la mise en page de l'imprimante ou le choix de la cartouche d'encre relèvent de la logique métier propre à l'imprimante ; le CAP vérifie uniquement si l'iFay a le droit d'utiliser l'imprimante
Implémentation des protocoles de communication réseau : Le CAP définit le flux logique et les formats de messages pour la vérification d'autorisation, mais ne prescrit pas l'implémentation spécifique des protocoles de transport réseau sous-jacents. Par exemple, que le terminal communique avec iFay_Runtime via WebSocket ou gRPC, le CAP n'impose aucune restriction
Mécanismes de sécurité internes des systèmes d'exploitation des terminaux : La gestion des permissions utilisateur, l'isolation par bac à sable, la sécurité des processus et autres mécanismes propres au système d'exploitation sont hors du champ de compétence du CAP. Le CAP collabore via des interfaces d'intégration avec le système d'exploitation. Par exemple, le mécanisme de bac à sable applicatif d'Android est géré par Android lui-même ; le CAP émet des instructions de contrôle d'accès via les interfaces fournies par Android

1.3 Relations avec les autres sous-projets

Le protocole CAP entretient des relations d'interaction clairement définies avec les sous-projets suivants au sein de l'écosystème iFay :

Sous-projet	Description de la relation	Frontière d'interaction
iFay_Runtime	Principal appelant du CAP. iFay_Runtime est responsable de la gestion du cycle de vie et de l'ordonnancement des instances Fay. Lorsqu'un Fay a besoin d'accéder aux ressources du terminal, iFay_Runtime initie les demandes de contrôle en son nom	iFay_Runtime → CAP : Initie les demandes de vérification d'autorisation ; CAP → iFay_Runtime : Retourne les résultats de vérification et les informations de session
Registration_Authority	Dépendance d'infrastructure de confiance du CAP. Registration_Authority est responsable de l'enregistrement du matériel, des logiciels et des systèmes d'exploitation des terminaux, et distribue les Verification_Keys aux terminaux	Registration_Authority → Terminal : Distribue les Verification_Keys ; les terminaux utilisent les Verification_Keys pour vérifier les signatures des Authorization_Descriptors
Descriptor_Issuer	Source des justificatifs d'autorisation du CAP. Descriptor_Issuer, autorisé par une Natural_Person ou un Official_Post, est responsable de la génération et de l'émission des Authorization_Descriptors	Descriptor_Issuer → Fay : Émet les Authorization_Descriptors ; le Fay présente les Authorization_Descriptors pour initier les demandes d'accès aux terminaux
Sous-système de gestion des identités	Source d'informations d'identité du CAP. Le CAP référence les identifiants d'identité des Fays lors de la vérification d'autorisation mais ne participe pas à la création et à la gestion des identités	Gestion des identités → CAP : Fournit les informations d'identifiant des Fays (dépendance unidirectionnelle)

Le principe de conception du protocole CAP est de maintenir la cohésion de ses propres responsabilités : effectuer uniquement la vérification d'autorisation et la gestion du contrôle, en laissant la gestion des identités, le raisonnement intelligent, la logique métier des ressources et autres responsabilités aux autres sous-projets de l'écosystème.

1.4 Scénarios d'application

Le scénario d'application principal du protocole CAP est : un iFay prend le contrôle du terminal de son hôte humain, utilisant les logiciels et invoquant le matériel du terminal comme le ferait un humain.

Dans ce scénario, l'hôte humain (Natural_Person) accorde le contrôle partiel ou total de son terminal à son iFay, qui exploite les logiciels clients du terminal (tels que navigateurs, clients de messagerie, logiciels bureautiques) et les dispositifs matériels (tels que caméras, microphones, dispositifs de stockage) en son nom. Le protocole CAP garantit que durant ce processus :

Légitimité de l'autorisation : Le terminal peut vérifier que l'iFay a effectivement été autorisé par l'hôte humain, plutôt qu'il s'agisse d'un accès non autorisé et illégal. Par exemple, si l'iFay de Zhang San tente d'opérer l'ordinateur portable de Li Si, le terminal refusera l'accès en raison de l'absence de justificatifs d'autorisation émis par Li Si
Disponibilité hors ligne : Même lorsque le terminal est hors ligne, tant que l'iFay détient un Authorization_Descriptor valide, il peut toujours accéder légitimement aux ressources autorisées. Par exemple, lorsqu'un utilisateur active le mode avion en vol, son iFay peut toujours continuer à utiliser les logiciels bureautiques sur l'ordinateur portable grâce au fichier d'autorisation hors ligne préalablement stocké
Coordination multipartite : Lorsque plusieurs Fays ou des Fays et des utilisateurs humains ont simultanément besoin d'accéder à la même ressource du terminal, le protocole CAP fournit des capacités de transfert de contrôle et de gestion des modes d'accès aux ressources. Par exemple, un utilisateur est en train de prendre des photos avec son téléphone lorsque l'iFay a également besoin d'utiliser l'appareil photo pour scanner un document — le protocole CAP coordonne l'ordre d'utilisation entre les deux
Sécurité et contrôlabilité : Toutes les opérations de vérification d'autorisation et d'accès aux ressources peuvent être auditées, et l'autorisation peut être révoquée à tout moment. Par exemple, si un utilisateur constate un comportement anormal de son iFay, il peut immédiatement révoquer son autorisation pour toutes les ressources du terminal, et les sessions actives de l'iFay seront terminées de force

Le même cadre protocolaire s'applique également aux scénarios coFay — les entités Fay collaboratives, autorisées par un Official_Post, prennent le contrôle des terminaux organisationnels pour exécuter des tâches collaboratives.

1.5 Principes de conception fondamentaux

Le protocole CAP suit le principe de conception fondamental de priorité au hors ligne, complément en ligne.

L'autorisation hors ligne (Authorization_Descriptor) est le mécanisme principal. Les terminaux ne devraient pas être complètement privés des droits de prise de contrôle d'un Fay en raison de l'indisponibilité du réseau. Si un Fay a préalablement été autorisé par son hôte humain, cette relation d'autorisation devrait être stockée localement sur le terminal sous forme de fichier chiffré, permettant au terminal d'effectuer indépendamment la vérification d'autorisation en mode hors ligne. L'Authorization_Descriptor est l'implémentation concrète de ce concept — c'est un fichier de description d'autorisation chiffré stocké localement sur le terminal, contenant la portée des ressources, les types de permissions et la période de validité pour lesquels le Fay est autorisé. Le terminal peut effectuer la vérification via le Descriptor_Validator local sans nécessiter de connectivité réseau.

Les tickets en ligne (Trusted_Ticket) sont le mécanisme complémentaire. Dans les environnements connectés, les Trusted_Tickets fournissent des capacités d'émission d'autorisation en temps réel et de consultation de l'état de révocation, compensant les insuffisances de l'autorisation hors ligne en termes de réactivité et de vitesse de réponse aux révocations. Lorsque les services en ligne sont disponibles, le terminal peut obtenir le dernier état d'autorisation via les Trusted_Tickets ; lorsque les services en ligne sont indisponibles, le terminal bascule automatiquement vers la vérification locale de l'Authorization_Descriptor, garantissant la continuité du service.

Les considérations fondamentales de ce principe de conception sont :

Disponibilité en priorité : Les interruptions réseau ne devraient pas empêcher un Fay de fonctionner ; l'autorisation hors ligne garantit la disponibilité de base. Par exemple, lorsque le signal du téléphone d'un utilisateur est interrompu dans le métro, l'iFay peut toujours continuer à utiliser les applications hors ligne du téléphone grâce au fichier d'autorisation local
Sécurité renforcée : Les tickets en ligne fournissent des garanties de sécurité en temps réel plus fortes lorsque le terminal est connecté, incluant la révocation instantanée et les ajustements dynamiques de permissions
Dégradation progressive : La transition du mode en ligne au mode hors ligne est fluide et ne provoque pas d'interruption soudaine du service. Les Trusted_Tickets émis en ligne peuvent être convertis au format local Authorization_Descriptor pour une utilisation hors ligne. Par exemple, un utilisateur autorise son iFay à utiliser l'appareil photo via un ticket en ligne sous Wi-Fi ; lorsque l'utilisateur quitte la zone de couverture Wi-Fi, l'autorisation passe automatiquement en mode hors ligne et reste effective